This application relates, generally, to the use and structure of removable electronic circuit cards and, more specifically, to allow personal computers or other hosts to use media specific card commands through a reader and/or host software that does not support these commands.
Recently, the small-format flash memory cards, such as the Compact Flash Card, Secure Digital (SD) Card, the Multi-media Card (MMC), xD, and the Sony Memory Stick/Memory Stick Pro, have achieved wide consumer acceptance. These devices are primarily designed for consumer electronic devices such as digital cameras and flash-memory music players. However, it is desirable that they also have convenient connections to personal computers for uploading and downloading data.
The different cards have different electrical interfaces and often commands specific to the media that can be used a host for the card. Further, card protocols may not only differ between card form factors, but also between various cards of the same form factor, since these cards are started to be overloaded with additional functions which may differ from one card to another. The commands often have unique functions such as special input-output (I/O) and security operations. As the uses of such cards become more diverse and they are used in ever more types of applications, these new applications will often involve functions or commands that are lacking in existing protocols.
Examples of commercially available non-volatile memory cards that have different mechanical and/or electrical interfaces include the related MultiMediaCard (“MMC”) and Secure Digital (“SD”) memory cards that are available from SanDisk Corporation of Sunnyvale, Calif., assignee of the present application. There are other cards that conform to standards of the International Organization for Standardization (“ISO”) and the International Electrotechnical Commission (“IEC”), an example that is widely implemented being known as the ISO/IEC 7816 standard.
The physical, electrical, and communication protocol specifications for the MMC are given in “The MultiMediaCard System Specification” that is updated and published from time-to-time by the MultiMediaCard Association (“MMCA”) of Cupertino, Calif. MMC products having varying storage capacity such as 128 megabytes in a single card are currently available from SanDisk Corporation. These products are described in a “MultiMediaCard Product Manual,” Revision 2, dated April 2000, published by SanDisk Corporation, which Manual is expressly incorporated herein by this reference.
The newer SD Card is similar to the MMC card, having the same size except for an increased thickness that accommodates an additional memory chip. A primary difference between them is that the SD Card includes additional data contacts in order to enable faster data transfer between the card and a host. (A version of the MMC card with additional data contact is also available—see version 4.0 of the MMC specification cited above.) The other contacts of the SD Card are the same as those of the MMC card in order that sockets designed to accept the SD Card will also accept the MMC card. The electrical and functional interface with the SD card is further made in such a way that the sockets designed to accept the SD card can also be made to accept the MMC card. The specifications of the SD card are available to member companies of the SD Association (SDA).
Cards made according to the ISO/IEC 7816 standard are of a different shape, have surface contacts in different positions, and a different electrical interface than the MMC and SD Cards. The ISO/IEC 7816 standard has the general title of “Identification cards-Integrated Circuit(s) Cards with Contacts,” and consists of parts 1-10 that carry individual dates from 1994 through 2000. This standard, copies of which are available from the ISO/IEC in Geneva, Switzerland, is expressly incorporated herein by this reference. ISO/IEC 7816 cards are particularly useful in applications where data must be stored in a secure manner that makes it extremely difficult or impossible for the data to be read in an unauthorized manner. The small ISO/IEC 7816 cards are commonly used in cellular telephones, among other applications.
As noted above, as such memory cards are used in new applications, they may have a need of functions or commands lacking in the existing version of a protocol. This situation can be illustrated with respect to FIG. 1. As shown on the upper portion of FIG. 1, the goal is the exchange of commands and data between a particular application, say in a secure data transfer or e-commerce application, on the host side and on the card side. To implement this, the commands will need to be transmitted between the host and the card, where the lower portion of FIG. 1 shows some of the software layers on the host side and some of the firmware layers on the card side. An instruction from the host's application layer will be passed through the operating system, file layer and the device (card) driver, ending up in protocol in which it can be transmitted to the card. Within the card, the instruction will then be taken up by the device layer firmware, which handles standard card operations and passed on to the application layer of the firmware. Depending on the arrangement being used, the instructions in the transmission protocol will either be exchanged directly from the host to the card or through a reader or hardware adapted, which may have its own software/firmware layers used to translate from one protocol to another. Where problems can arise is that at some stage in the translation between these layers, the intended instruction of the application may lack a corresponding command at some point along the way.
As one example, a card is often connected with a PC host through use of a hardware adapter (e.g. for USB) that accepts commands from the host system. However, many of the media specific commands are not available in the protocol by which the host and the hardware adapter communicate, even though the host application of the PC host wants to transmit these commands to the card application.
FIG. 2 shows a system of a first host and a card, where the card 101 is connectable to the host 151 either directly, for example by insertion into the slot 153, or through some sort of adapter. The card firmware is indicated by FW 105. (Both with respect to card firmware 105 and reader firmware 335 in FIG. 3, it will be understood that, more generally, these functions can be implemented in hardware, software, or some combination of these.) An example of such a host 151 could be a digital camera or a telephone. A number of types of such cards are in current use and being developed. The card and host can communicate through a number of specific protocols, many of which are specific to particular media and which may include various media specific commands. Since many of the commands may be media specific, there can be cases where, when such a command is to be exchanged between a host and the media, somewhere along the line the command will need to be translated into another protocol, which may not support the media specific command. If this other protocol does not have a corresponding command, the host will not be able to successfully issue the command.
For example, in addition to its use in a host, it is also common for a user to access a card on a personal computer. For example, it is common for a card that has been used in, say, a digital camera and want to access the photos stored in the card on a personal computer. This situation is shown by the box diagram of FIG. 3. The card 101 is typically put into communication with the personal computer PC 351 through of a card reader 331 having a receptacle 333 for the card 101, although in other cases the card may be directly attached to PC 351. The reader 331 and PC 351 will typically communicate through a protocol that, at least to some extent, differs from that used by the card 101 to communicate with the host 151. The reader 331 translates a command from the PC 351 into a form suitable for the card 101 based on firmware 335 (or hardware, software or some combination of these), where it is generally understood that this function can be performed any combination of software and hardware, depending on the implementation. This process is shown schematically in FIG. 4.
To give a concrete example, in FIG. 4 the reader 331 will be taken as a USB device that communicates with the PC 351 using the SCSI command set and the card 101 will be taken as an SD card. As the PC 351 and reader 331 uses the SCSI protocol, when the host wants to issue a command to the card through the reader, it issues command 401 in the SCSI command set. To transfer the command 401 to the reader, it is placed in an USB wrapper 403, transmitted along the USB connection to the reader, and there the USB wrapper is removed. The card reader 331 will then translate the command 401 from the SCSI command set into the corresponding command or commands 405 in the SD set, allowing it to be passed on to the card 101; however, for the reader to translate a given command between the SCSI command set and the SD command set, there needs to be an equivalent command in both sets. Consequently, if the host wants to perform, for example, a read of the secure area in the SD card by issuing a secure read command in the SD protocol, as there is no such SCSI equivalent, there is no way for the reader to translate this as it is not found in the SCSI command set and the read request will be considered to be to an area for which the user has insufficient access rights. The same situation will arrive for other media specific command for various card types where there is no equivalent SCSI command or commands for the host to send to reader in a protocol it understands.
Consequently, such a media card specific command cannot be passed to the card from the host without changing the firmware of the adapter or the reader which hosts the media card to introduce corresponding commands for the protocol it uses to communicate with the host. Similar situations can also arise, even without a separate card reader, whenever a protocol change is needed somewhere along the communication path or when the host's operating system is unaware of card features.
In dealing with this issue, typical approaches either change the adapter firmware to support special commands for passing such instructions through the adapter or create new commands in the reader-host protocol, each tailored to the specific media command such as those corresponding to send challenge, receive response and other commands in the SD card's protocol. These approaches tend to be impractical for a number of reasons. For one, the protocols are usually based on a standard which, to be useful, needs to be broadly accepted and usually tends to prefer less complicated command sets. Consequently, it is difficult to introduce various new, media specific commands into the protocol command set as new media are introduced and existing media evolve. If instead the adapter's firmware is changed to allow for special commands to pass through those media specific commands that it does not itself support, the software of each vendor for such adapters would need to accept and make the appropriate firmware changes.
More generally, even when the card is in direct connection with the host, card protocols need to be updated as new card commands are introduced, such as application specific commands. For example, the MultiMediaCard System Specification may define a card protocol containing a set of commands that may be transmitted directly to a MultiMediaCard. If there is a need for a new command, the specification or standard may need to be updated to support the additional command. Although existing protocols can be expanded and standardized to incorporate the new functions, this introduces compatibility problems with older card versions or cards manufactured by other vendors, largely undermining the utility of a standardized protocol. Additionally, some card protocols may not be easily modified to accommodate additional commands. For example, if a card protocol utilizes six bits of information to encode a command, then the card protocol may only define a command set having 64 commands. If there is a need to support more than 64 commands, the card protocol may need to be modified or redesigned to extend the command set. Further, although the protocols may be adapted to incorporate new commands, this is likely to only be a temporary solution as ever more applications arise to extend the uses of cards.